The healthcare software market has traditionally been dominated by large, complex, workflow-based applications that help healthcare employees perform their jobs in a more efficient manner. These applications are very good at providing services to the internal staff at the organization that purchased/installed them. However, they are less successful at providing services to people indirectly affiliated with the organization—examples are patients or satellite clinicians who refer in to the large organizations. The applications are simply too complex to provide strong benefit to these affiliated users, who just need high-level or overview information.
With the advent of the Internet, vendors began to see the opportunity to provide applications to reach out to these affiliated users. Web-based products can sit on top of the large core applications, and provide a simpler user interface which has more value to the end user. Vendors connected their web application and their core application, and were able to bring the web applications to market.
As these Internet applications began hitting the market, a new problem emerged. Most healthcare organizations deploy clinical/administrative systems from more than one vendor (best-of-breed approach). As the vendors created their Internet applications, customers found that they would have to deploy separate web-based applications to gain access to data across the enterprise. The affiliated users would have to log into to separate applications to view related data. This clearly was not ideal, and demand rose for a web-based product that would provide a single view over all the data in the enterprise, no matter where it resided.
Vendors attempted to tackle this problem via the use of interfaces. In these interfaces, the web application would not communicate with the large core applications directly. Instead, the web application communicated directly with a duplicated database under its control. That duplicated database was fed information from the core applications via interfaces. This approach allowed the web application to display information from multiple sources, providing the single view that the affiliated users were looking for. However, there are problems with this approach, such as the interfaces are typically non-trivial to maintain—there are support/implementation costs, as well as personnel costs; the web-application-owned database now has a copy of data from other systems with elaborate efforts being made to ensure that the duplicated data is up-to-date, and does not age. For example, if a change is made to data in the core product, that change needs to be uploaded into the web-owned database. Otherwise, users of the web application will view inaccurate data—a critical problem in the healthcare industry. Additionally, the duplicated database typically runs on a less reliable system than that of backend systems and uses a higher level code, that is generally less efficient than the operating system level code of backend systems, for maintaining the duplication of data.
HIPAA regulations govern privacy and security of patient-related healthcare information. All applications displaying such information need to make sure that infrastructure is in place to comply with HIPAA regulations. Since the web application has a database of healthcare data, that application needs to build even more infrastructure to handle the security of that database. The vendor may have to replicate security that already exists in their core application.